fix(plugins): report updates that completed, not ones that were queued - #460

The bug

run_scheduled_updates_with_changes() answers "which plugins have fresh data". It did so by snapshotting plugin_last_update, calling run_scheduled_updates(), and diffing the two.

But run_scheduled_updates() only enqueues:

if last_update == 0.0 or (current_time - last_update) >= interval:
    if self._synchronous_updates:
        self._execute_update_now(plugin_id, plugin_instance, current_time)   # inline
    else:
        self._enqueue_update(plugin_id, current_time)                        # queued

_enqueue_update() sets state and pushes to a queue. The update runs on the worker thread, and plugin_last_update is stamped there — after this method has already returned. So the second snapshot was always identical to the first, and the method returned [] every time. Only the synchronous kill-switch path ever worked, which is why the wiring reads as correct.

Why it matters

Vegas is the caller. _tick_plugin_updates_for_vegas() feeds that list to mark_plugin_updated(), which drops the cached content for a plugin whose data moved. With the list permanently empty, a segment kept scrolling whatever it was first built from — exactly what coordinator.py warns about in its own comments:

Without this the pending-update flags are never consumed and a segment keeps rendering whatever it was first built from — last night's live game still shown as live the next morning.

Measured on a live 512×64 rig: zero update ticks in twenty minutes, with weather, stocks and news all updating on schedule.

The fix

Report what has completed since the last poll rather than what this call enqueued. The worker records each finished update in a small ledger; the call drains it.

That costs one tick of latency — Vegas polls roughly every 4 seconds — and is correct regardless of which side of the queue the work lands on, so it keeps working if the sync/async default ever changes.

Failure paths are deliberately excluded. They stamp plugin_last_update too, to space out retries, but no fresh data exists.

Verification

On the rig where it was found: 0 update ticks before, 208 in twenty-five minutes after, naming real plugins (ledmatrix-flights, stock-news, geochron, news…).

A note on the tests, because the first version of them was worthless. The behavioural tests drive the ledger directly, so they passed with both production call sites deleted — mutation testing caught that, not review. There is now also a structural test asserting the invariant at the source: wherever a successful update stamps plugin_last_update, it must record the completion. Writing that immediately caught something I would have missed — _record_update_failure stamps the same field and must not be included.

Mutation-checked: removing either call site, removing both, and dropping the drain's clear() are all caught.

Full suite: 2066 passed, with the same 4 failures present on main (unrelated — tmpdir, web API, state reconciliation).

Summary by CodeRabbit

• Bug Fixes
  • Improved plugin update reporting so updates completed in the background are now detected reliably.
  • Synchronous and asynchronous updates are reported consistently.
  • Prevented duplicate update notifications while ensuring multiple completed updates are captured.
  • Improved handling of updates completed during ongoing checks and under concurrent activity.